An operating system logon session, such as a WINDOWS (from Microsoft Corporation of Redmond, Wash.) logon session, is conventionally generated for each successful authentication on a computer. An initiating process, such as the Winlogon.exe process in a WINDOWS environment, loads a GINA (Graphical Identification aNd Authentication) which presents a logon dialog box to an interactive user. The GINA may be default operating system GINA (which in WINDOWS is the MSGINA.dll) or a third party GINA operating in lieu of, or in addition to, the operating system GINA. Multiple GINAs may be employed in a chain. The logon dialog box requests user information such as a username, password and optionally target domain. In stand-alone operating environments, the interactive user is authenticated and then proceeds to operate according to the access rights and privileges set forth in the user profile identified during authentication. In network environments, the date of a network roaming profile for a local interactive user may be compared against the date of a local profile with any newer files in the roaming profile used to update the files already present on the system. In a network environment where the local interactive user is logged onto a client and wishes to access a server-hosted session, conventional methods of accessing the remotely hosted session assume that the interactive user accessing the remote session and the local user in the client operating system logon session are one and the same. Communications from the remote session are directed to the operating system logon session. When the local interactive user logs off from the remote session and leaves the client, the operating system logon session ends and a new logon session is started for the next local user.
FIG. 1 depicts the conventional process by which multiple interactive users logon to a client in order to access remote sessions. The sequence begins when the interactive user logs on to the operating system domain, such as a WINDOWS domain, at the client (step 2). An operating system logon session, such as a WINDOWS logon session is generated and associated with the interactive user (step 4). A network-stored roaming profile is then acquired for the interactive user based on the information used to logon to the operating system domain (step 6). The network-stored profile is retrieved and the client may be checked for the presence of a local profile. If a local profile exists on the client, the profiles are compared with newer files in the roaming profile being used to update the profile of the interactive user. The interactive user then submits an authentication password to access a server-hosted domain or an application on the server-hosted domain (step 8). The interactive user is required to submit authentication for each application or domain he is attempting to access (step 9). This may require multiple authentications. After the interactive user has completed the remote session and logs off from the remote session, the operating system logon session must also be logged off (step 10) before a subsequent interactive user is able to access the client (step 12). The subsequent interactive user is required to begin a new operating system logon process (step 2) before accessing a remote session.
Conventionally, the switching of interactive users on a client or kiosk in communication with the server necessitates the ending of both the remote session and the operating system logon session and the subsequent generation of a new operating system logon session and new connection to a remote session for a new local interactive user. Unfortunately, the requirement of a new operating system logon session for each new local interactive user results in sub-optimal wait times for users in time-sensitive locations such as hospitals. For example, if a first doctor accesses a computer in a hospital and then responds to a patient, a second doctor using the computer is not going to want to wait for authentication processes required with an entirely new operating system logon session. Additionally, conventional shared workstations are subject to unauthorized use and make it difficult to provide accountability for the actions taken by users at the workstations.